test/pytest: the raiser has to be the statement under test (#432) - #939

…ompt#432)

`raises-catches-setup`, entry 5 and the last on VACUITY_MODES.md's list of what to add
next. The statement COUNT rule refused a `pytest.raises` block holding more than one
top-level statement. Two shapes are ONE statement and still perform the setup inside
the block, so the count saw nothing:

    with pytest.raises(psycopg.errors.UndefinedObject) as exc:
        _setup_then_run(conn)          # a HELPER CALL: one statement

    with pytest.raises(psycopg.errors.UndefinedObject) as exc:
        for stmt in (setup_sql, sql_under_test):   # a COMPOUND STATEMENT: one
            conn.execute(stmt)                     # statement holding two

Both were measured against the shipped scan reporting `1 passed`, exit 0, zero
offences, with the setup raising and the statement under test never running. The two
arms that recorded them as residuals now assert the refusal, so the closure is a
measurement rather than a sentence.

THE FIX IS NOT A DEEPER COUNT, for the reason the entry always gave: counting
recursively would also refuse a legitimate single-statement loop. It is a claim about
WHICH statement raised, in two rules.

NO COMPOUND STATEMENT, and all nine kinds rather than the one the inventory named. The
document named the `for` spelling; `if`, `while`, `with` and `try` nest identically, and
a rule catching only `for` would close an example rather than a mode. The kinds are
looked up by name instead of written out, because `TryStar` and `Match` exist only on
newer Pythons and a missing attribute would be a NameError at import rather than a rule
that quietly does less.

NO CALL TO A FUNCTION DEFINED IN THE SAME FILE, anywhere in the statement. Such a
function can run any number of statements and nothing in the block says which failed. A
call to an IMPORTED function, or to a METHOD, is the thing under test and stays allowed.

THE RULE TURNS ON WHERE THE FUNCTION IS DEFINED, NOT ON THE STATEMENT BEING A CALL, and
that is what makes the budget zero. Measured over the corpus before writing either rule:
five `pytest.raises` blocks in real code, NONE touching a database -- four call
`build_and_install`, imported from the module under test, and one calls a method. The
scan reports no offence on any of them.

MEASURED FIRST, AND IT CHANGED THE DESIGN. The entry suggests "a helper that runs
exactly one statement and owns the assertion", which would be a DB helper. There are
zero SQL-raising `pytest.raises` blocks in the corpus, so that helper would have had no
call sites -- an instrument with nothing exercising it, which is the thing this
directory refuses to build. The shape rules close the same mode against the code that
exists.

THE RESIDUAL IS A METHOD. A method that performs setup and then the statement is
invisible to this rule, and no static rule can see inside it. Stated rather than hidden,
and pinned by the arm that accepts the method shape.

Prove by removal, five mutations, each by exact string with a parse assertion, and the
restore verified byte-identical rather than by `git diff`:

    control                           34 passed
    compound rule removed              2 failed
    local-def rule removed             2 failed
    only `for` counts as compound      1 failed
    only a bare call is searched       1 failed
    the message filter narrowed        4 failed

TWO OF MY OWN ARMS COULD NOT FAIL UNTIL I MUTATED THEM. The local-def rule searches the
WHOLE statement, and my first arm used a bare call only -- so narrowing the search to
`Expr` changed nothing and `x = _helper()` stayed open. And the every-compound-kind arm
exists because without it, reducing the kind list to `For` alone was invisible.

AND THE RULES FIRED WHILE PRINTING NOTHING. The message assembly buckets offenders by
substring, and the bucket's filter was the exact sentence of the COUNT rule -- so both
new rules refused the run and the layer said `refuses this run: .` with an empty list.
The arms reddened on a missing message while the refusal itself worked, which is a
guard that cannot be told from an unfired one. The filter is now the common tail of all
three phrases.

RECORDED WHILE I WAS IN THERE: the comment defending the one-source-line offence phrase
cited selftest 440 grepping this file and counting the copies. **Selftest 440 no longer
exists** -- commandprompt#927 deleted it under the harness-independence rule. Nothing greps this
source for the phrase today, so that form is now a convention rather than a guarded
property; what is still load-bearing is the RUNTIME string the pytest arms match, which
a split f-string would not change at all. The comment says that instead.

Gate:
    harness_selftest   588 checks, 588 passed + 0 failed + 0 unrunnable, PASSED
    driver-free job    9 files, 161 passed, psycopg absent from the venv
    full corpus        241 passed with a cluster on pg18a

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Uf6UoeBRZYLQZa4KxNiw8a

…not have moved

I claimed a closure I can defeat three ways, and @jdatcmd's review named the residuals.
Measuring them settles the classification against me:

    a `for` loop over two statements                     REFUSED
    the same two as a list comprehension                 allowed
    the same two as a tuple of calls                     allowed
    a helper defined in ANOTHER file                      allowed
    an honest one-statement helper in THIS file           REFUSED (a false positive)

A comprehension and a tuple are EXPRESSIONS, not compound statements, so a rule about
statement kinds cannot see them; `local_defs` is built from one file, so moving the
helper one file over defeats it. Neither is a contrivance -- both are ordinary Python.

So by this document's own convention the mode stays in section 3, the section-2 row is
withdrawn, and the refused count goes back to 28 with not-refused back to 44. The arms
derive it: refused=28, not_refused=44, and `raises-catches-setup` is not in the refused
set. Section 5's entry now says "Done, and it NARROWS rather than closes", beside the two
other entries that say the same thing.

THE ARM THAT EXISTS TO CATCH THIS OVERCLAIM DID NOT CATCH IT, and that is the part worth
keeping. `test_the_mode_this_layer_only_narrows_is_still_listed_as_open` required the mode
to be named in section 3 -- and section 3 keeps a back-reference for every mode that
MOVES, "`X` is now closed", so the id is present in section 3 in BOTH states. My first
version wrote the closure into section 3, added the row to section 2, moved the count to
29, and the arm passed. Its own docstring says what it was for: "A document that quietly
moved the mode to section 2 would claim a closure this scan does not make."

It now also requires the mode to be named OUTSIDE a closure back-reference, and to be
absent from section 2. Proven by removal, each shape of the overclaim separately:

    control (the document as it stands)   1 passed
    entry rewritten as a back-reference   1 failed
    row added back to section 2           1 failed
    both, which is what my branch did     1 failed

AND MY FIRST TIGHTENING WAS WRONG IN THE SAME FAMILY. I wrote
`section3.split("is now closed")[0]`, which truncates at the FIRST back-reference in the
section -- today `insert-wrote-no-rows`, which sits above this entry -- so it reported
"only as a back-reference" about a document that names the mode correctly. A positional
test over a section holding several back-references is a test about their order. It is
per-line now.

Gate:
    harness_selftest   588 checks, 588 passed + 0 failed + 0 unrunnable, PASSED
    driver-free job    10 files, 183 passed, psycopg absent from the venv
    full corpus        266 passed with a cluster on pg18a
    derived counts     refused 28, not refused 44, named 72

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Uf6UoeBRZYLQZa4KxNiw8a